Is this really an issue ? Wouldn't attributes which would be "taken over"/adopted by the FIG project automatically get the Fig\Attributes namespace, making them essentially a different attribute anyway ?

If the namespace would not change to Fig\Attributes, I think it would be prudent to define a procedure around this, i.e. will the namespace change ? if so, when will the namespace change (next major) ? will there be an alias to the old namespace ? and if so, for how long ? etc etc

The namespace will change! But depending on how long it'll take people might want to impmement it right now.

When the taken over attribute then extends the new fig one implementations will still work, so people can use it immediately.

Maybe a heading would give it a bit more attention?

I'm not sure this needs a call out at this point. Any new attribute we include would be in this repo, in our namespace, and may or may not be identical to something that previously exists. So from the POV of our downstreams, there's no difference.

If we do end up with attributes that are heavily inspired or cloned from some existing use case, we can add a document or section or something for it at that time, as a courtesy. But I don't think it needs a formal call out at this point.

I see this as an invitation to existing distributed attribute-maintainers to move them over to the FIG.

Thinking about this at this point already should make this a more welcoming experience for them and they know exactly what is to be expected - but also makes it clear that requesting an account takeover and then not complying is not going to be a lifelong advertisement via the FIG.

I'm not sure this needs a call out at this point. Any new attribute we include would be in this repo, in our namespace, and may or may not be identical to something that previously exists. So from the POV of our downstreams, there's no difference.

IMO there is a difference.

Let's take @DaveLiddament's DaveLiddament\PhpLanguageExtensions\Friend-Attribute as an example.

A new Attribute Fig\Attributes\Friend would be created here. People realize that and can prepare their code to use it. But they will only be able to use it once the attribute is actually released. That can take quite some time. Perhaps not as long as with PSR-5 but still it might be more than 2 weeks.

During this time the "old" legacy DaveLiddament\PhpLanguageExtensions\Friend is already available. Which is functionally identical to the new Fig\Attributes\Friend attribute. And once the Fig-one is released the "old" one will extend the Fig one.

So during this takeover time it is already possible to use the attribute in a meaningful and forward-compatible way. As after the release the DaveLiddament\PhpLanguageExtensions\Friend will extend Fig\Attributes\Friend and everything that is then using the former can then be modified to use the later without breaking anything. New tools will only use Fig\Attributes\Friend as the other one is not adding anything new.

Describing this from the start seems to me not unimportant to allow an easy transfer of existing attributes where the process and the advantages are clear to everyone from the start.

Or am I missing something?

During this time the "old" legacy DaveLiddament\PhpLanguageExtensions\Friend is already available. Which is functionally identical to the new Fig\Attributes\Friend attribute.

Right here is the crux of my issue. Will it be functionally identical? Will we adopt is wholesale as-is, with no modifications?

Maybe! Sometimes that will make sense. (#[Pure] is virtually identical to PHPStorm's version, as there's not much to even do.) But that won't always be the case. I do not want to state or imply that we're going to pull in existing 3rd party attributes without going through the same level of review, scrutiny, and polish that a virgin attribute would have.

Compatibility with an existing attribute is certainly a factor in design, but it's far from the only. (The same is true of nearly all PSRs to date. We do not want to be shackled to what happens to be popular, if there is a better design available with a reasonable migration path.)